The present invention relates generally to cloud-based servers that execute web browsers, and more particularly to a server-based mechanism for sharing intermediate representations of commonly used script files between different tabs, windows, frames, panels, or other browser display components for viewing web content.
JavaScript® is a well-known scripting language used to allow computer applications to access software objects within other applications. When first invented, JavaScript® comprised code snippets that were sparsely embedded in a web page, and was used to manipulate the Document Object Model (DOM). JavaScript® has since matured and is now used in a more library-like manner. That is, instead of embedding JavaScript® code among other HyperText Markup Language (HTML) code in a given web page, JavaScript® code is encapsulated in separate files. Each file may be associated with a different functionality or set of features and is included in the web pages. In this manner, a given JavaScript® file can be included in different web pages, and one web page can include more than one JavaScript® file. This helps improve the reusability and modularity of JavaScript®.
By way of example, the common features of a website, such as common user interface logic, may be provided as separate JavaScript® files. These files are included in multiple web pages within a website and provided to a user when the user accesses the website. Thus, when the user interacts with one web page to enter data, for example, the user is presented with a user interface having generally the same look and feel as the other web pages in the website.
The Apple® website illustrates this type of usage very well. Particularly, it puts most of its JavaScript® code into several JavaScript® files in a modular manner. Then, it uses the same JavaScript® files across several different web pages to provide the same or similar functionality across those web pages. At the time of writing, Apple's® home page (www.apple.com), Apple's® Mac® page (www.apple.com/mac), and Apple's® iPhone® page (www.apple.com/iphone) include seven (7) of the same JavaScript® files, while the Mac® and iPhone® pages themselves share three (3) additional JavaScript® files between them.
Typically, web pages import JavaScript® files within the same domain/website. In addition, however, web pages can also import JavaScript® files from one or more different domains/websites. For example, Google Maps, Facebook, and other such services provide JavaScript® Application Programming Interfaces (APIs) so that other developers can develop applications that access the services provided by their JavaScript® files. In such cases, the JavaScript® files would be located at google.com or facebook.com, or some other common repository, and included in the web pages from other websites that intend to use Google Maps or Facebook services.
Additionally, there is another category of standalone JavaScript® files that are used as libraries. Some examples include, but are not limited to, Prototype, JQuery, and Yahoo!® UI (YUI) Library. These libraries “wrap up” common logic into related files and abstract the interfaces used to manipulate web pages. Such libraries make creating and building web pages easier and more maintainable. A large number of well-known websites, some of which are listed by the Pingdom® website (http://royal.pingdom.com/2008/06/11/javascript-framework-usage-among-top-websites), for example, are now using such JavaScript® libraries to facilitate the construction and maintenance of websites.
Currently, most web browsers support the opening of multiple web page instances simultaneously. For example, a web browser that opens a web page containing frames in framesets or iframes, which load other web pages, maintain multiple web page instances. Another example is the “multi-tab browser.” As is known in the art, a multi-tab browser allows multiple tabs to be open at the same time in a single browser window. Each tab is a display component of a web browser that allows a user to view web content such as a web page. Additionally, other display components exist that are able to display web content. Such components include, but are not limited to windows, frames, and panels, or other construct that enables a user to view and interact with web content. However, for simplicity sake, each of these different components are referred to herein as “tab” or “display component.”
Typically, multi-tab browsers execute on single end user devices, such as a desktop or laptop computer. However, even resource-limited devices, such as mobile devices, provide multi-tab browser functionality. For example, the iPhone® and iPod® provide their users with the Safari browser. Similarly, Android provides the WebKit-based browser. Such browsers, although they may not actually visually display multiple tabs, still provide the multi-tab functionality. In addition, there is now an ongoing trend in that each tab executes as its own separate process to facilitate stability and security, while the core functions of the browser execute as another process. Some examples of modern browsers that use this approach are Google Chrome and Microsoft's Internet Explorer (IE) 8.
Based on the current trends of importing external JavaScript® files and the use of multi-tab browsing as described above, there is a high probability that web pages opened in multiple tabs will include or use the same JavaScript® files. Such a situation is likely to happen, for example, when a user clicks a link in one tab to open a new tab that loads a different web page from the same website. In these cases, some of the JavaScript® files included with the web page in the newly opened tab are likely to be the same as those included with the web page in the current tab. In another scenario, a user may simultaneously open a plurality of tabs, each loading a different website. The web pages in each different tab may all use a common set of services from another entity, such as Google Maps or Facebook, and therefore include the same JavaScript® files from Google Maps or Facebook. In yet another scenario, the web pages in different tabs may all use third-party JavaScript® libraries such as Prototype or JQuery, and therefore, include copies of the same JavaScript® files.
JavaScript® is used in an increasingly library-like manner. This trend continues to strengthen due at least in part to the increased use of HTML5 and the need to optimize different web sites for use with an array of different types of devices having different form factors (e.g., the different screen sizes for a smartphone and an iPad®). Such needs help to fuel the development of a variety of different JavaScript® libraries to perform these functions. Thus, the size of external JavaScript® files tends to increase and the logical structure of the JavaScript® files tend to become more complex.
Still, given these facts, no one has attempted to optimize the resource usage and performance of a browser. Where different tabs include the same JavaScript® files, the browser will repeat the parsing of each file to the JavaScript® syntax tree, and “just-in-time” (JIT) compile the files to bytecode. Additionally, largely same copies of the data structures will also be stored in multiple places in the memory.
As previously stated, web browser applications are typically executed on a single, user device. However, there is a growing trend towards executing browser applications on a server disposed in a cloud network. Particularly, a cloud-based server executes the core browser functionality including interpreting the JavaScript® files, parsing a given web page into the DOM tree, and constructing a render tree from the DOM tree. The user device renders the visual elements contained in the render tree in the order specified by the render tree. The render tree is persistently synchronized between the cloud and the user's device to ensure that the user's device has the most up-to-date rendering information.
Executing a browser application on a cloud-based server does not solve the issues mentioned above with respect to executing the browser application on a single end host device. In fact, migrating the execution of the browser to the cloud network may complicate these issues and make the problems worse. Particularly, a cloud-based server permits connections between the browser application and many different end host devices, each of which will likely access many different web pages and related files. Because the browser applications still may not utilize JavaScript® files as libraries, a browser application executing on a cloud-based server could also repeat the parsing of a JavaScript® file to the JavaScript® syntax tree, and JIT compile the file to bytecode even though that same JavaScript file may have already been parsed and JIT compiled for another tab. Further, like a user device, a browser application executing on a cloud-based server could store many of the same data structures in multiple places in memory. Considering the number of different user devices that may simultaneously connect to the browser application executing on the server, the amount of memory and other resources that the user devices could use when using the browser application is concerning.